Dr. Douglas McIlroy's speech in ‘1968 NATO software engineering conference’ on “Mass produced software components” is widely credited for launching today's ‘software engineering’ and Component-based software design and engineering (or ‘CBSE’). Since then most of the software engineering research has been focused on reusable components and increasing reuse of code or modules. Ultimate dream is to build new/custom applications by assembling pre-build COTS (Commercially Of The Shelf) components. The main focus of the research is to invent components having desirable properties such as non-context-specific, standardized, generic, highly flexible or configurable, for example (i) to be reusable in more applications and/or (ii) to make the component easy to reuse by being flexible to configure for each application etc.
The primary purpose or essential benefits of the reusable parts is ‘reuse’. But it is also possible to invent new kind of parts having other useful benefits other than ‘reuse’. In other words, other new kind of parts can be invented, which can be used for not only creating a large application but also maintaining the applications at lower cost and/or complexity. The parts belong to the new kind can be designed to serve different but useful purpose or offer useful benefit. So the new kind of components addresses problems that are not addressed by any other known kind of components.
Component Based Design (CBD) and Component-Based Engineering (CBE): The physical CBD-products (e.g. automobiles, cell-phones or computers) are built using various kinds of parts such as (i) component-parts such as CPU, DRAM-card, car-engine, gearbox and CD-player etc., and (ii) ingredient-parts such as silicon, steel, cement, plastic, metals and alloys etc. Where the CBD/CBE-products imply products that are created by assembling the component-parts. The parts belong to each of the kinds has different set of unique characteristics and primary purpose for serving different but useful benefits. Some parts (e.g. most of the ‘ingredient-parts’) are ideally suited for ‘reuse’, while other parts are designed for serving other useful purposes.
For example, although desirable it is not necessary for the physical component-parts to be reusable, but some of the useful benefits for component-parts include, for example, it is easy to replace any time in the future and (ii) it is possible to dissemble even large a component (e.g. jet-engine) having many sub-components as a unit and fix any problems and possible to reassemble the large component. In other words, the physical components are offering useful benefits (other than reuse), such as each component can be easily assembled for building the CBE-product. Also the component can be easily disassembled as a unit for maintenance (e.g. redesigning or fixing any short comings) or to replace by a better component. This ability to easily replace a part (e.g. CPU, DRAM or Hard Drive) is useful to extend the life of a product at lower cost.
For example, if one of a kind experimental spacecraft or jet fighter is built by assembling custom designed components, it is likely that most of the core large components and coupling interfaces of the components are custom designed. Even if the large core components are not reusable, each component is assembled such that they are simpler pre-defined custom loosely coupled interfaces, so that the component can be replaceable (i.e. easy to disassemble or reassemble as a unit). This property of the physical components is desirable, because each component can be disassembled for redesigning and testing outside of the product, at any time in the future (e.g. to repair or to improve). But if a large component, having many tightly coupled devices and subcomponents, is assembled by tightly coupling each of its devices and subcomponents separately into a product, it then requires removing each of the tightly coupled devices and subcomponents to remove the large component. Encapsulating all the devices and subcomponents of the component in a loosely coupled replaceable container minimizes this complexity, since the component can be replaced as a unit (e.g. as long as its interfaces are loosely coupled to make the component replaceable, even if the component is not reusable and interfaces are custom designed).
It is desirable to invent software components, which can offer comparable benefits such as components that are easier to replace or easier to maintain (e.g. to fix problems or add new features). For example, today almost no large GUI component having a dozen or more large GUI subcomponents (e.g. Charts, graphs, maps or trees) is encapsulated in a loosely couple replaceable component, where each subcomponent is included using an object instance of a reusable GUI class and by using custom application data for initializing the object instance. Each of the object instance of a reusable GUI class is often tightly coupled by implementing many lines of application code for getting, processing application data and using the data for initializing or constructing a subcomponent, where all this associated application code makes the subcomponent tightly coupled. Hence to include the large GUI component, it is required to include many tightly coupled object instances and associated application code for including respective subcomponents. To remove the large GUI component, it then needs removing all the tightly coupled subcomponents and associated application code.
This invention discloses new kind of software components called self-contained components (SCC) and replaceable self-contained components (RSCC). The earlier U.S. Pat. Nos. 7,827,527 and 7,840,937 (in this chain of continuation-in-parts) disclosed methods for creating reusable GUI classes for a GUI API, which is capable of encapsulating such large GUI components (that is using many reusable GUI classes for including GUI subcomponents) in a replaceable class. It is possible to invent new kind of software components, which are not necessarily ‘reusable’ but can serve other useful purposes or offer benefits (that are not offered by any other known kind of software components). One of the essential benefits of the physical component-parts is: either directly increasing or indirectly allow increasing the degree of useful factors (i) division-of-labor, (ii) specialization and (iii) mechanization (i.e. automation in case of software development). These factors hereafter referred to the 3-CBE-factors.
According to some software research papers, up to 80% of the software engineering effort is to deal with maintaining/changing the existing software, for example, to build a better/newer version or to support new requirements, such as, changing business needs or government regulations. This is especially true in case of successful software and need to be maintained or updated to use for many years. So many software experts feel large software components that can be easily adaptable to changing or evolving requirements (e.g. business needs) is as useful as the reusable components. So it is desirable to invent new kind of components, which can be easily adaptable by redesigning its source code to satisfy evolving needs of its application.
It is also desirable for the components to reduce the cost of building similar components, if a similar component is needed in a new application. For example, by making it easier to take a copy of a component's source code (e.g. where the source code can be conceptually/logically equivalent to a blueprint of a physical component) and redesigning the copy to create a new version/model of the component to satisfy unique needs of the new application. This kind of reuse is code reuse (e.g. analogues to reuse of blueprint of a physical component, or reuse of design and know-how) but not component reuse (since component reuse means using a component in multiple applications without any redesigning of the component).
The software engineering and design of software application can benefit from experiences gained in the mature field of industrial engineering. For example, many automobile designers are concerned with giving easy service-access to the parts that need more frequent servicing or maintenance, to minimize the overall cost of ownership and maximize satisfaction. For example, in case of automobiles it is desirable to easily replace parts that are prone to wear-and-tear. Likewise, in case of computers, parts (e.g. DRAM, CPU or Hard drive etc) that can be upgraded to extend the usefulness or life of the computer. If a component requires little or no effort to detach (or disassemble) or re-attach (or re-assemble), such component is said to be having highest degree of service-access. It is desirable to have high degree of ‘service access’ (or ‘replaceability’) to each part that requires frequent maintenance, or likely to be upgraded (e.g. DRAM, HardDrive, CD-player or CPU) to satisfy owner's evolving or expanding needs.
Today software engineering and CBSE have many gaps compared to the CBE (Component Based Engineering) of physical products. So it is required to invent new kind of software components and process to fill some or all the gaps (e.g. the S-CBE-factors). The CBSE and CBE have many similarities, which must be analyzed to find and comprehend the gaps for inventing solutions to fill the gaps. Also CBE and CBSE have many differences, especially in mass production and product-lines (or product-families). For example, automobile industry deals with just one automobile product-family. An airplane industry (e.g. engineers in the airplane industry) deals with airplane product family. But software industry (e.g. engineers in the software industry) deals with many product families such as compilers, ERP, video games, OS, banking/finance and many others. Although each of them is a software product, each product family requires deferent domain specific components and domain expertise.
For example, it is also desirable to analyze evolution of ecosystems for reusable components (e.g. third-party component vendors) since introduction of early product models for various product families/lines (e.g. automobiles, computers or Airplanes). More percent of components can be reused across product models within (i) a mature crowded product-line (e.g. automobiles evolved for over a century) or (ii) a product-line (or product-family) whose components are more conducive for standardization. For example, components for cell-phones or computers conducive for standardization, because software can be used for differentiation, variations or customization. Likewise, each year hundreds of new models of cars introduced in just one automobile product-line, so such crowded product-line conducive to an ecosystem for third-party component vendors to build non-core components such as auto-battery, CD-player or ACs etc. Many of the core components (e.g. engine or gearbox) are custom designed for a product model and may not be readily reusable (i.e. without redesigning the couplings) across product-models (e.g. Toyota Camry, Corolla or Honda Accord). Also each component is often redesigned and evolved for each new model-upgrade every few years.
But software engineering is dealing with many product-lines or product-families, such as, OS, compilers, browsers, Word-processing, Spreadsheet, banking, games, medical-records or manufacturing etc. And more new software product-lines are emerging each year, such as online-games (e.g. Zynga), search engines for social networks or applications for iPad/Iphone/Android etc. So it is harder to invent large reusable components for using across such diverse product-lines or product-families. Also most software product-families are less conducive to an ecosystem for third-party component vendors and most of the software components are less conducive for standardization. However, the physical components and CBE for physical products offer useful benefits other than reuse, so it is desirable to invent software components that can offer benefits comparable to the other useful benefits (e.g. 3-CBE-factors throughout the life of a component for future maintenance or enhancements).
So it is desirable to find similarities with CBE to locate any gaps and invent components to fill the gaps. It is possible to invent components that not only can offer high degree of replaceability but also have high degree of autonomy, for example, to redesign the component either to improve or to satisfy evolving or changing requirements. Such a replaceable autonomous component can be disassembled from the product as a unit and refined and tested with high degree of autonomy. For example, a replaceable autonomous GUI component can be easily disassembled and refined. Its GUI features and coupling-interfaces may be tested autonomously ‘outside of the application’ by implementing simple test application. Once satisfied with the features, performance and/or quality, the autonomous GUI component can be re-assembled in to the application.
The components having high degree of autonomy offer certain benefits, which are proven to be very useful in design, development and long-term maintenance from the experiences of the industrial engineering. The benefits are: Increasing the degree of autonomy of a part increases (or indirectly allow increasing) degree of (i) division-of-labor, (ii) specialization and (iii) mechanization or automation.
The autonomous components can be more conducive for automation or specialization. So they can also indirectly allow increasing automation or specialization. For example, introduction of the interchangeable components in early 18th century not only increased degree of specialization but also increased mechanization in mass-producing the interchangeable components, for example, by using tools such as jigs, casting, dies/moulds or forging. Another example, the increased degree of autonomy due to standardized interfaces of interchangeable components allowed Ford Motor Company to automate mass-production of the cars by inventing moving assembly line. But, such improvements in mass-production are not applicable to the software development.
However, for example, directly increasing useful factors such as increasing division-of-labor for software components might lead to indirectly increasing automation, by opening up possibilities for inventing new tools or processes. For example, the direct benefits for the ‘interchangeable parts’ is increased division-of-labor and allow specialization, while automation such as Ford's moving assembly line is indirect benefit, where the moving assembly line is not very useful or practical without the interchangeable parts introduced a century earlier (between years 1809 and 1818).
The components having high degree of autonomy is also very useful for building and maintaining the software applications, since each of the (sub)-components can be refined more autonomously for satisfying evolving needs, new technologies or know-how (e.g. expertise wisdom gained during/from previous versions and use-cases in field). For example, engineering historian Petroski suggested in 1992 book “The Evolution of Useful Things” (i) Continual refinement is the usual rule and (ii) Engineers constantly find shortcomings in their designs & fix them “little-by-little”.
Today's state of the art design of each large physical product (e.g. car or PC) is result of many decades of evolution by improving each of its components ‘little by little’ autonomously. For example, designer of most of the physical components (e.g. car-engine, Hard Drive, CPU or DRAM) have been refining them little by little for decades autonomously from respective physical products.
It is desirable to identify each of the large autonomous-parts (i.e. components innately having high degree of autonomy) in an application and make them replaceable (i.e. easy to disassemble and reassemble). Each of the large software applications contains multiple large sub-systems innately having high degree of autonomy, but today such large autonomous sub-systems are not identified and designed as replaceable adoptable components. Any sub-system that is innately having high degree of autonomy could be designed as replaceable component. If such autonomous components are identified and each autonomous component is designed as a replaceable (e.g. by having loosely coupled interfaces) adoptable component, it reduces the cost of evolving the component, for example by reducing the cost and complexity of refining “little-by-little”.
Brief summary of “CBD-Process”: The CBD (Component-Based Design) and CBE (Component-Based Engineering) steps for building the physical products can be broadly divided into three main stages (or steps), which are briefly summarized below:
Step or stage 1—Design & Development:
(1a) Cost or complexity of CBE design mainly comprises: Designing a product by partitioning it into component/sub-components, where each large (sub)-component may be further partitioned into sub (sub)-components, and so on. This successive partition creates a hierarchy of components and subcomponents. The main activity of the CBE design comprises (i) creating the hierarchy of components/subcomponents and (ii) designing the loosely coupled interfaces for each component/subcomponent in the hierarchy. (1b) Cost or complexity of designing and building all the components mainly comprises: Independently design and build each of the prototype components and test each of the components independently. (1c) Assemble the components to build a set of working prototype product(s) and test the product. Fix any problems (e.g. functional or design) by refining/replacing each of the components and test. Repeat the ‘fix-and-test’ cycle until satisfactory components and product is created, which is the final ‘golden’ reference model or version for manufacturing (i.e. mass production). Total complexity or cost for designing and building of a CBE-product comprises costs for 1a, 1b and 1c.
Stage or Step 2—Mass Production:
Using the ‘golden’ as a reference to define engineering tolerances for each of the components and its coupling interfaces (e.g. for assembling and to permit proper collaboration between the components) to mass-produce ‘interchangeable parts’. Then set up an assembly line to assemble the components for mass-producing products. Although coupling interfaces of components are often changed in stage-one, often discouraged in stage-two.
Stage or Step 3—Maintenance or Evolution:
Every few years, each of the successful product-model (e.g. Camry or Accord) must be substantially redesigned for upgrading to a new model/version. A physical CBE-product is often evolved by evolving each of its components. The new model often needs redesigning many of the large core components/sub-components for improving them based on factors such as new-innovations, expertise and wisdom gained from previous designs or customer-feedbacks and fixing any shortcomings etc. Fix any problems (e.g. functional or design) by refining/replacing each of the components and test the components. Repeat the ‘fix-and-test’ cycle until a satisfactory components and product is created, which is the ‘golden’ reference model for manufacturing (i.e. mass-production in step 2).
In case of software products, mass production is nothing but making copies on CDs or host the software on a server for the world to use or download the software product. Hence obviously stage-two (i.e. mass-production) don't apply to the software applications. But it is possible to apply stage-1 and 3 for designing and building the software applications (if one wish to design and built using such CBSE, and when comparable replaceable autonomous components invented). The increased degree of autonomy of various components used in building/assembling the product (i.e. software application) is useful in each iterative ‘fix-and-test cycle’ of the components not only during the initial development but also in the future maintenance and evolution.
It is not necessary that component-parts are reusable for the CBE. For example, if prototype for one-of-a-kind spacecraft or experimental nuclear powered rail-engine were to be built in the future, it likely will be built by employing CBE design steps and assembling component-parts. Where most of the large component-parts likely are custom designed and it is not necessary that the large component-parts are reusable for design and development of the one-of-a-kind CBE-product. However it is desirable to have the ability to ‘fix-and-test’ each of the large new custom component-parts used for building the CBE-product during the step-1 and step-3. Likewise, it is desirable to invent comparable software replaceable-components having high degree of autonomy, which can make it simpler to apply frequent “fix-and-test’ cycles during step-1 and step-3. For example, to apply ‘fix-and-test’ cycle for each component-part, it is desirable to easily disassemble the component-part for redesigning and testing and also desirable to easily reassemble the component-part. A replaceable component having higher degree of autonomy makes it simpler to test it independently outside of its container product. Once a satisfactory prototype is created then step-2 may be employed only for the physical products, if it is required to mass-produce the physical CBE-product.
This background of the invention is forced to use example from the experiences of industrial engineering and design methods of the physical CBE-products (i.e. products created by assembling physical components), because no comparable research effort is found in the research of the software components and CBSE for using as reference or for using as prior-art. Comparing today's CBSE with CBE and researching differences expose many gaps in the CBSE. Comprehending and analyzing the missing capabilities lead to inventions ‘specific to software’ for filling the gaps. Although software components and applications are different from physical components and CBE-products respectively, discovering the hidden benefits and characteristics or nature of the physical components/CBE help invent software components having necessary equivalent characteristics for offering comparable benefits.
A product-family is said to be crowded product-family, if dozens of new product-models are designed each year. Examples for crowded product-family include automobile product-family, cell-phone product-family or computer product-family. A product-family is said to be mature product-family, if the product was invented decades ago and early product-models were very successful and substantial research has been done for decades to constantly improve the product-models and various components by third party component vendors. For example, product-families such as automobile product-family, computer product-family, Swiss-analog-watches or Airplane product-family were invented decades ago and today they are mature product families and product-models belong to each product-family is evolved by evolving their components autonomously (where many of the components are evolved by third-party component vendors).
If few simple facts are analyzed, it is not hard to realize that, it is nearly impossible to achieve the stated objective or goal of few CBSE researchers: Inventing CBSE for building software applications by assembling third-party (COTS) components as computer or cell-phone makers build respective product-models by using third-party (COTS) components. Where ‘COTS parts’ means ‘Commercial Off The Shelf parts’. The CBSE researchers overlooked few simple facts such as (i) the industry for each product-family (i.e. for computers or cell-phones) is both mature and crowded (ii) the designers of each-product-model (e.g. a new model of computer or cell-phone) can rely on software to differentiate from competition and (iii) each industry is dealing with just one product-family (while software industry must deal with many product-families, such as compilers, games, OS, RDBMS, ERP, Medical-Records, Finance or Manufacturing etc.). Even if it is possible to achieve the stated goal of the CBSE researchers, the goal can't be achieved without first discovering ‘what is true CBD’ and inventing right kind of software components that can enable true CBD.
It is desirable to have high degree of autonomy (or replaceability) for the software modules or parts in an application, if the modules or parts need to be evolved by redesigning or refining over the time for maintenance or for releasing upgraded versions/models of the application. It is desirable for many custom parts to be easily adaptable to changing needs of the application. Where examples for custom parts include software modules or classes custom designed for an application or family of applications in a given domain (e.g. Nokia created family of Operating-Systems for wide range of Nokia cell-phone models). Any large part having high degree of autonomy (also designed to be easily replaceable) and conducive to preserving the autonomy (or replaceability) reduces the cost and complexity of evolving the part over the life of the container product or application (e.g. during its maintenance cycles in future).
Hence it is desirable to invent new software components along with tools and methods that not only can offer high degree of replaceability but also conducive to preserve the high degree of replaceability throughout the life of application. The new software components are only conducive for preserving the replaceability, but for example, any unplanned, unstructured or quick fixes (e.g. patches between two major releases) by employing a bad design could erode or dilute the higher degree of replaceability over time. When that happens it is desirable to periodically redesign (e.g. refactoring of its code) the coupling interfaces of the components for restoring optimal degree of replaceability for the replaceable components, where the coupling interfaces are useful for allowing the component to communicate or collaborate with other components/parts of the application.
The following are two kinds of physical parts just as an analogy or examples to illustrate two kinds of parts belonging to the opposite sides of the replaceability scale. Here some parts are ideal for designing as replaceable, while it is not possible to design the other parts as replaceable. For example, the physical products are created by using different kinds of parts, such as: (i) component-parts (i.e. components) such as CPU, DRAM-card, car-engine, gearbox and CD-player etc., and (ii) ingredient-parts such as silicon, steel, plastic, metals and alloys etc., which are often used for building the components or products.
Certain parts such as ingredient-parts can only offer 3-CBE-factors up to certain point. For example, even ingredient parts can be manufactured and tested autonomously, so offer the three benefits up to making them. But an ingredient-part cannot offer the benefits (e.g. autonomy or replaceability) after using it for making its container-part/product. For example, it is not practical to remove ‘silicon’ in an IC-chip to refine/replace the silicon after making the IC-chip (for maintenance of ‘silicon’ outside the IC-chip in the future). Often such parts require lot more effort for composing (e.g. tight coupling the parts). But for maintenance at any time in the future, any component such as an auto-engine or CD-player of a car can be disassembled, refined/tested (‘outside’ of the car), and reassembled. Only intended purpose of this analogy is, to illustrate that it is desirable to preserve the autonomy (i.e. higher degree of replaceability or service-access) of the parts that need to be changed during future maintenance.
Only purpose of these analogies and examples of physical parts is to just give laymen examples, to illustrate the gaps in the CBSE and advantages of parts that can be designed to have high degree autonomy and replaceability, if the parts need to be replaced or to allow ‘fix-and-test’ during long-term maintenance of the product. So these analogies and example of physical parts must not be used for any other purpose, except for understanding the gaps and general contextual meaning of ‘replaceability’ and to comprehend various methods presented in this disclosure for ‘preserving the replaceability and autonomy’ for redesigning the part to satisfy evolving needs.
The software modules need not necessarily be comparable to the physical components or parts. For example, there are no software parts comparable to ingredient-parts such as silicon. Almost all the software parts (even very large sub-systems) offer certain degree of replaceability and autonomy, although they offer very low degree of replaceability and autonomy. But it is possible to invent new kind of software components that can substantially increase replaceability and autonomy, even for large sub-systems.
For example, if 900 lines of application-code is implemented for building a part (e.g. part-X) and including into an application, then part-X is considered having low degree of replaceability, if it requires changing 400 lines in one or more non-exclusive application files to properly remove part-X. Where the non-exclusive files contain application code for other parts of the application, so it requires finding and properly removing only the code sections of part-X. But it is desirable to increase the degree of replaceability and/or autonomy of part-X. For example, if part-X can be implemented and tested independently as an autonomous module such as a class definition and part-X can be assembled into an application by implementing 9 lines in an application file (e.g. where 2 lines is for instantiating and initialising an object instance of class for part-X and 7 lines for creating necessary communication code for part-X).
Also it is desirable to effectively remove the part-X as a unit by removing or changing the 9 lines implemented for assembling the part-X. In this example, the object instance of part-X's class decreased required code from 400 lines to 9 lines for disassembling/assembling part-X, resulting in substantially increasing the degree of replaceability. Furthermore, it is desirable to make the source code for the class definition for part-X has high degree of autonomy to redesign part-X (e.g. to satisfy evolving needs), and to test part-X autonomously, for example, by making it simpler to create test application that assembles object instance of part-X.
Hence although such a large component innately have high degree of autonomy, the total construction code of the component end up broken into multiple code-sections and included in one or more non-exclusive files of the application. So the component end up having very low degree of autonomy (making it harder to redesign) and also very harder to replace. Where non-exclusive file for an autonomous component implies, that the file contain code sections for other autonomous components and/or other parts of the application (in addition to containing code sections for the autonomous component). An exclusive file for an autonomous component implies, a file containing code for no other component or part of the application, except the code sections for the autonomous component.
Today the CBSE have many unknown gaps and/or shortcomings that must be discovered and analyzed for inventing solutions. For example, it is desirable to invent new kind of software components for filling some of the gaps. This invention discloses a new kind of software parts that innately have high degree of autonomy, so more conducive to design as replaceable components (i.e. new kind of components having very high degree of service-access and autonomy) and allow preserving the replaceability during the future evolution of the software. It is desirable to have high degree of autonomy not only during building a large software component but also to preserve the high degree of autonomy of the large software component for redesigning to satisfy evolving needs in the future.
In addition to having higher degree of (i) replaceability and (ii) autonomy for design, development and maintenance/evolution of each of the components, it is desirable to increase degree of automation by inventing tools, utilities and mechanisms, for example, (i) to create or reduce communication code required when assembling the components in to an application and (ii) managing the communication code during maintenance. For example, it is desirable to detect any missing services for a component or incompatible coupling interfaces between any two collaborating components in an application.
Today software research community first defined, “what is a software component?” and loosely extrapolated CBD (Component-Based Design/Development) is not much more than using the software components (or ‘component models or frameworks’, where each model or framework defined by groups of experts). It is well known or obvious that: If there are errors in the references used for any extrapolation, the results of the extrapolation most likely are wrong. Since mankind has centuries of expertise with CBD of physical-products and physical components, it is desirable to find obvious, irrefutable or easily verifiable facts and aspects about ideal CBD for physical-products and physical-components for using the facts and aspects as references to extrapolate essential properties (or true nature) of the physical-components that can enable ideal CBD. Once the essential properties are discovered, it is desirable to invent software components having the essential properties (e.g. for enabling true CBD for software-products).